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AUTOMATED  SERVICE  DELIVERY 
ABSTRACT 


Customer  Service  organizations  are  currently  faced  with  conflicting  challenges  from 
two  sources: 

Users  who  want  better  service  yet  lower  service  prices. 

The  parent  organization  which  looks  to  service  to  provide  increased 
service  margin  while  at  the  same  time  wanting  service  to  continue  to 
remain  competitive  in  the  market. 

As  a  result,  service  organizations  have  looked  toward  advanced  technology  to  find 
ways  to  provide  better  service  more  efficiently  (and  profitably).  Customer  service 
organizations  have  successfully  automated  certain  service  management  functions, 
such  as  call-handling,  dispatching,  and  parts  management,  with  sophisticated 
software  systems.  In  addition,  certain  diagnostic  and  support  implementation 
activities  have  been  built  into  the  computer  systems  themselves. 

This  report  details  the  development  of  service  automation  technology  by  showing 
industrywide  use,  as  well  as  specific  case  studies  of  leading  service  vendors  and  their 
service  automation  activities.  The  report  concludes  with  the  presentation  of  an 
"ideal"  service  management  system  that  incorporates  current  technology. 

This  report  contains  70  pages,  including  17  exhibits. 
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INTRODUCTrON 


SCOPE 


This  report  deals  with  specific  issues  of  high  Importance  to  customer  service 
organizations,  with  the  primary  focus  on  the  steadily  increasing  user  demand 
for  more  and  better  service  in  an  increasingly  competitive  marketplace. 
Service  organizations  will  find  themselves  under  greater  pressure  from  both 
users  and  internal  organization  to  increase  and  improve  service  and  to 
maintain  or  even  lower  service  prices  while  at  the  same  time  increase  their 
revenue  and  profit  contribution  to  the  overall  company  goals. 

As  a  result,  service  organizations  will  need  to  uncover  and  exploit  new 
revenue  sources,  both  in  the  types  of  services  provided  (e.g.,  software  support, 
unbundled  training,  systems  integration)  and  in  the  types  of  customers  (e.g., 
third-party  maintenance).  In  addition,  service  organizations  must  continue  to 
find  ways  to  provide  service  more  efficiently  and  effectively. 

One  such  way  is  to  gain  tighter  control  over  the  inherent  costs  associated  with 
the  delivery  of  service,  primarily  the  movement  of  engineers  and  parts  both  in 
the  field  and  at  service  locations.  By  optimizing  the  amount  of  time  an 
engineer  is  actually  engaged  in  service  activities  versus  traveling  or 
communicating  with  the  service  organization,  the  service  organization 
optimizes  the  billable  costs/service  revenue  ratio,  thus  increasing  service 
margin.    In  addition,  the  correct  inventory  of  necessary  spares  contributes 
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more  obvious  benefits  (e.g.,  reduced  downtime,  reduced  travel  time,  increased 
user  satisfaction). 

Customer  service  organizations  in  the  computer  industry  have,  not  surpris- 
ingly, looked  to  increased  automation  as  a  method  of  gaining  such  increased 
control  over  costs.  Software  and  turnkey  systems  have  been  developed  to 
accomplish  such  service  functions  as  dispatching/call  handling,  inventory 
management,  and  billing.  Early  systems  were  patterned  after  traditional 
manufacturing  systems  (one  leading  prod  uct,  SERVICEMAN,  was  developed 
and  sold  by  ASK  Software,  a  leading  vendor  of  manufacturing  software 
systems)  which  emphasized  "real  time"  control  over  resources  (e.g., 
manpower,  tools,  parts).  As  these  systems  developed,  integration  of  service 
functions  became  the  key  focus  of  these  systems. 

Presently,  service  organizations  require  increased  integration  of  service 
management  functions  (accounting,  account  histories,  etc.)  with  service 
delivery  functions  (dispatching,  product  histories).  In  addition,  more  sophisti- 
cated applications  are  beginning  to  incorporate  remote  diagnostics  into 
service  management  systems.  Furthermore,  "real  time"  information  handling 
needs  are  now  "too  slow";  service  organizations  need  to  plan  into  the  future, 
rather  than  remain  largely  "reactive." 

This  report  will  analyze  the  development  of  automated  service  delivery 
activities  within  customer  service  organizations  from  simple  dispatching  and 
parts  tracking  systems  to  current  fully-integrated  service  management 
systems.  In  addition,  the  report  will  analyze  "user"  (service  organizations) 
needs  for  such  systems,  based  on  interviews  with  service  management  of 
leading  manufacturer  and  third-party  service  organizations.  When  possible, 
case  studies  will  detail  specific  application  of  in-house  and  "packaged" 
systems.  Lastly,  a  series  of  recommendations  will  conclude  the  report,  based 
on  the  development  of  an  "ideal"  model  of  a  (not  so)  future  service 
management  system. 
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METHODOLOGY 


This  report  was  prepared  using  a  two-prong  research  effort: 

Primary  research  was  conducted  in  February  !  987,  involving  focused 
interviewing  of  logistics  managers  or  MIS  officials  at  16  manufacturer 
and  third-party  service  organizations.  The  focus  of  these  surveys  was 
experiences  with  automated  service,  primarily  field  service  manage- 
ment systems  (FSMS)  and  remote  support  systems  (RSS).  The  question- 
naire used  for  this  effort  is  contained  in  Appendix  A.  In  addition, 
vendors  of  FSMS  packages  and  portable  terminals  used  in  conjunction 
with  FSMS  applications  were  surveyed  concerning  their  products. 

Secondary  research  was  performed,  making  use  of  INPUT'S  specialized 
library  containing  information  on  products,  companies,  and  applications 
of  customer  services  activities. 

As  always,  INPUT  welcomes  questions,  suggestions,  and  comments  about  this 
report  or  any  of  INPUT'S  research  products  and/or  services. 
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EXECUTIVE  SUMMARY 


This  executive  summary  is  designed  to  help  the  busy  reader  quickly  review  the 
research  findings  of  this  report.  Each  main  point  is  summarized  as  an  exhibit 
and  an  accompanying  script  is  given  on  the  facing  page.  The  format  is 
designed  to  facilitate  use  of  the  executive  summary  as  an  in-house  overhead 
presentation. 

The  focus  of  this  report  is  to  demonstrate  the  importance  of  automated 
service  systems  as  a  way  of  improving  service  delivered  to  users  while 
reducing  the  costs  involved  with  service  activities.  Service  organizations 
have  traditionally  used  in-house  and  packaged  software  systems  to  automate 
dispatching,  call  handling,  and  parts  management  functions  (replacing  less 
efficient  paper-based  systems);  increased  pressure  on  service  organizations  to 
improve  service  and  increase  profitability  while  maintaining  reasonable 
service  prices  has  encouraged  service  organizations  to  increase  service 
management  and  delivery  automation.  A  further  objective  of  service 
automation  is  the  improved  integration  of  these  automation  efforts. 

The  following  summary  details  the  development  of  service  automation  efforts, 
up  to  current  automation  activities  of  leading  manufacturer  and  third-party 
service  organizations.  The  summary  concludes  with  an  "ideal"  service 
automation  system  that  integrates  both  service  management  and  service 
delivery  functions. 
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A. 


THE  DEVELOPMENT  OF  AUTOMATED  SERVICE  DELIVERY 


•  Early  computer  service  management  required  the  accumulation  and  storage  of 
basic  information  concerning  hardware  maintenance  activities  and  the 
dispatching  and  delivery  of  service  to  the  company's  user  base.  Service  calls 
were  telephoned  in  by  the  user,  field  engineers  (FEs)  were  dispatched  to  the 
user  site  by  phone  or  by  radio,  and  all  information  about  the  process  was 
accumulated  and  stored  in  a  paper-based  file  management  system. 

•  By  the  1960s,  most  computer  manufacturers  had  replaced  their  unwieldy 
paper-based  systems  with  (by  today's  standards)  primitive  batch-processed 
computer  systems.  In  the  early  1970s,  these  systems  were  greatly  improved 
with  the  addition  of  optical  character  recognition  techniques,  reducing  the 
paper  flow  from  the  FE  to  service  management. 


•  It  was  not  until  the  mid-1970s  that  service  management  automation 
progressed  to  today's  level,  exemplified  by  systems  developed  by  Western 
Union,  Datapoint,  and,  most  particularly,  Texas  Instruments  that  automated 
call  handling,  dispatching,  parts  tracking,  and  other  service  functionality  on  a 
real  time  basis.  By  this  time,  FE  reports  were  coded  for  faster  data  entry, 
and  later  in  the  1970s  some  companies  experimented  with  handheld  terminals 
that  would  improve  FE  communications. 


•  Currently,  almost  all  field  service  organizations  use  some  level  of  automated 
service  management  system,  most  In  the  form  of  In-house  developed  or 
packaged  Field  Service  Management  Software  Systems  (FSMS).  In  the  next 
section,  INPUT  will  examine  current  use  of  such  systems. 
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EXHIBIT  11-1 


DEVELOPMENT  OF 
AUTOMATED  SERVICE  DELIVERY 


1960                1970                1980  1990  2000 

I  1  


PAST   ►    PRESENT   ►  FUTURE 


PAPER-BASED  FSMS  SOFTWARE  AI/EXPERT 

PHONE  OR  RADIO  SYSTEMS 


REMOTE  DIAGNOSTICS 


REMOTE  SUPPORT 
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B.       CURRENT  FSMS  FUNCTIONALITY 


®  In  March  1987  INPUT  surveyed  16  leading  manufacturer-based  and  third-party 
service  organizations  concerning  their  current  requirements  for  specific 
service  management  functions  as  well  as  whether  that  function  is  performed 
by  their  current  system  (either  developed  in-house  or  "packaged"). 

®  Not  surprisingly,  most  service  organizations  place  the  highest  requirement  on 
traditional  service  management  informational  needs—parts  (inventory) 
management  and  dispatching  (call  handling).  Accounting  functions  (specific- 
ally invoicing)  were  less  of  a  requirement  for  service  organizations  surveyed, 
suggesting  that  they  would  prefer  to  leave  those  activities  to  accounting 
people  within  the  larger  organization. 

•  These  same  service  organizations  reported  a  low  requirement  for  remote 
diagnostics  within  their  service  management  system.  Indeed,  only  28%  of  the 
sample  currently  implements  remote  diagnostics  through  their  system,  while 
all  of  the  systems  manufacturers  surveyed  use  some  form  of  remote 
diagnostics  separately. 

•  The  separation  of  accounting  and  remote  support  functions  highlights  a 
weakness  within  today's  service  management  activities  since  the  lack  of 
integration  of  these  activities  with  other  service  automation  activities  leads 
to  less  efficient  management  and  delivery  of  service. 

•  In  the  future,  service  organizations  will  face  increased  pressure  to  provide 
more  efficient  and  effective  service  at  reduced  prices.  To  do  so,  service 
organizations  will  need  to  integrate  all  service  functionality  to  optimize 
service  efficiency. 
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EXHIBIT  11-2 


FSMS  USE 


Service  Function 


Requirement' 


I  I  I  I  I  I  I  I  I  I 


%  Receive 


Parts  Tracking 


Dispatching 


Accounting 


Remote  Diagnostics 


83% 


78% 


56% 


28% 


Sample:    16  Service  Organizations 
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C       PRODUCTIVITY  GAINS  RESULTING  FROM  AUTOMATION 


•  Service  automation  activities  improve  not  only  the  flow  and  availability  of 
information,  but  also  the  actual  delivery  of  maintenance  and  support  to  the 
user.  Certain  vendors  have  already  realized  productivity  gains  by  incor- 
porating such  advanced  applications  as  artificial  intelligence  (Al)  and  expert 
sytems  into  their  remote  support  offerings. 

•  Al  and  expert  systems  are  advanced  applications  that  mimic  human  reasoning 
by  "interpreting"  patterns  existing  in  a  data  base  (in  this  case,  a  problems  data 
base)  and  by  presenting  "recommendations"  based  on  the  probability  of  these 
patterns  occurring.  When  incorporated  with  remote  support,  those  applica- 
tions can  lead  to  the  ability  to  recognize  minor  intermittent  errors,  report 
these  errors,  and  recommend  necessary  steps  to  circumvent  or  correct  the 
error.  What  results  is  the  ability  to  provide  predictive  support  that  allows 
scheduled  replacement  of  a  unit,  rather  than  reactive  support  to  correct 
catastrophic  failure  of  a  system. 

•  DEC,  for  example,  has  improved  both  hardware  maintenance  and  software 
support  delivery  through  the  establishment  of  automated  support  centers,  such 
as  the  one  located  in  Colorado  Springs  (CO).  Data  General  has  realized 
similar  improvements  in  productivity  with  its  own  centralized  software 
support  centers. 
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EXHIBIT  11-3 


INPUT 

PRODUCTIVITY  IMPROVEMENTS  FROM 
AUTOMATED  SERVICE  DELIVERY  ACTIVITIES 


Company 

Support 
Implementation 

Productivity 
Gain 

IBM 

Expert  Systems 
for  Peripherals 

20-30%  Reduction  in 
Service  Costs 

DEC 

Remote  Support 
Center 

85%  of  Software  Problems 
Solved  in  45  Minutes 
or  Less 

DG 

Telephone  Support 
for  Software 

20-25%  Decrease 
in  Service  Incidents 
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THE  FUTURE  OF  SERVICE  AUTOMATION 


•  Service  organizations  are  currently  faced  with  building  pressures  from  three 
major  fronts: 

Users  who  are  requiring  improved  and  increased  services  while  pushing 
for  lower  service  prices. 

Larger  (manufacturer)  organizations,  which  push  for  increased  profit- 
ability, particularly  with  slowed  product  sales  growth. 

The  overall  competitive  environment,  which  reflects  the  importance  of 
system  availability  as  serviceability  in  the  user's  purchase  decision. 

•  All  of  these  pressures  have  forced  service  organizations  to  find  ways  to 
provide  service  and  support  more  efficiently  and  effectively  to  their  users. 
Service  organizations  have  already  successfully  automated  certain  functions 
within  service  management  (e.g.,  logistics  management,  dispatching,  remote 
diagnostics),  yet  this  increased  pressure  should  encourage  service  organiza- 
tions to  continue  their  progress  in  service  automation. 

•  The  minimum  functional  requirements  of  such  an  effort  are  shown  in  Exhibit 
II-4,  stressing  the  productivity  gains  available  through  the  efficient  integra- 
tion of  service  automation  capabilities.  All  of  this  technology  is  currently 
available  and  in  use  to  some  degree  by  service  organizations.  What  is  needed 
is  the  integrated  application  of  these  activities  which  will  result  in  better 
informational  flow  and  smoother  delivery  of  support  to  the  users. 


-  12  - 

©1987  by  INPUT.  Reproduction  Prohibited.  INPUT 


EXHIBIT  11-4 


THE  "IDEAL"  AUTOMATED  SERVICE  SYSTEM 


Complete  Functionality  -  Logistics,  Informational,  Accounting 


Single,  Accessible  Data  Base 


integration  of  Remote  Support  Activities 


Use  of  Al  and  Expert  Systems  Software 
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Ill       DEVELOPMENT  OF  AUTOMATED  SERVICE  DELIVERY 


A.       EARLY  DISPATCHING  SYSTEMS 

•  In  recognition  of  the  inevitability  of  product  failure,  product  manufacturers 
established  entities  designed  to  resolve  problems  for  their  customers' 
products.  Given  the  need  for  prompt  resolution  of  the  inevitable  problems, 
these  entities  were  set  up  to  be  able  to  provide  problem  resolution  at  the 
user's  site.  Thus,  these  entities  became  known  as  "field  service" 
organizations. 

e  it  also  became  necessary  to  keep  track  and  manage  the  activities  of  the 
service  organization.  Field  service  management  was  established  to  keep  track 
of  the  people,  tools,  and  parts  required  to  perform  service  at  users'  sites.  This 
also  created  the  need  to  communicate  (and  keep  track  of  such  communica- 
tions) between  service  management  and  the  field  service  personnel. 

•  Basic  informational  (data)  needs  for  the  management  included  the  following: 

Call  (from  users)  handling. 
Dispatching  (field  service  personnel). 
Parts  tracking  and  use. 
Failure  analysis. 
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While  call  handling  and  dispatching  was  nornnally  handled  by  telephone  or 
radio,  most  informational  processing  was  paper-based.  The  record  of  the  call 
was  handwritten,  handled  by  the  appropriate  people,  and  then  stored  (filed)  as 
a  master  file. 

By  the  mid-1960s,  most  service  organizations  had  replaced  their  unwieldy, 
all-paper-based  systems  with  primitive  (by  today's  standards)  automated 
systems  built  around  batch-processed,  keypunched  data  processing  systems. 
The  resulting  improvements  in  data  storage  and  handling  were  enormous, 
allowing  accurate  and  readily  usable  records  of  equipment,  customer  histories, 
and  service  routines.  Unfortunately,  service  reports  (by  the  field  engineer) 
were  still  handwritten,  data  entry  was  time  consuming,  and  communications 
between  field  personnel  and  management  were  still  primitive. 

By  the  1970s,  field  personnel  reporting  (handwritten)  techniques  were  replaced 
with  optical  character  recognition  (OCR)  techniques  which  automated  the 
process  of  taking  down  and  entering  information.  This  move  reduced  the  time 
needed  by  the  engineers  to  report  their  activities  (although  significantly 
limited  the  contents  of  their  communications)  and  reduced  the  time  necessary 
to  enter  the  information  into  the  computer.  Still,  communications  between 
field  engineer  and  service  management  were  primitive,  largely  because  they 
still  relied  on  telephone-  or  radio-based  communication,  independent  of  the 
automated  service  management  developments. 

By  the  mid-1970s,  progress  in  the  integration  of  communications  and  data 
handling  activities  was  being  made.  Western  Union  and  Datapoint  had  both 
developed  service  management  systems  into  which  engineer's  calls  were 
entered;  however,  the  first  company  with  a  truly  integrated  automated 
service  management  system  was  Texas  Instruments,  which  developed  its 
system  (FIS-I)  in  1976. 

Tl's  system  incorporated  regional  call  handling  and  dispatching,  resource 
allocation,  staffing  and  performance  modeling,  and  other  MIS  functions,  built 
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around  a  Tl  960  minicomputer  that  kept  track  of  the  activities  of  100  field 
engineers  working  out  of  38  service  locations  (1974  demographic  data). 

Tl  continued  to  develop  the  system  as  its  product  and  customer  base  grew, 
adding  improved  reporting  capabilities  that  showed  that  while  the  cost  per 
call  increased  (reflecting  the  costs  of  systems  development),  overall  service 
profitability  also  increased  as  a  result  of  reduced  callbacks  and  improved 
efficiency  while  on-site. 

Perhaps  the  most  significant  improvement  was  the  use  of  specialized  handheld 
terminals  by  the  field  engineers  (FEs),  which  replaced  the  use  of  handwritten 
reports  or  OCR  coded  forms.  While  the  OCR  forms  were  a  great  improve- 
ment over  completely  handwritten  reporting  forms,  they  often  required  an  FE 
to  memorize  confusing  codes.  Frequently,  the  engineer  put  the  wrong  code, 
unintentially  or  even  intentionally  (FEs  often  put  codes  that  they 
remembered,  just  to  make  sure  that  some  code  was  entered),  and  would  rarely 
be  able  to  remember  codes  when  questioned  later  about  a  specific  call. 

An  alternative  to  the  coded  methodology  was  automated  call  closing,  where 
an  FE  would  call  by  telephone  a  computer  operator  sitting  at  a  data  entry 
terminal,  who  would  enter  information  from  the  FE  at  the  time  of  call  close. 
Since  the  data  entry  person  was  skilled  at  data  entry,  and  since  screens  were 
frequently  menu  driven,  data  entry  errors  were  reduced.  Also,  FEs  could  work 
from  memory  or  informal  notes  without  having  to  memorize  or  translate  code 
(unfortunately,  that  task  was  placed  on  the  data  entry  person).  However,  this 
methodology  increased  telephone  costs  and  also  slowed  the  entry  of  data  into 
the  system. 

By  the  late  1970s,  improved  computer  design  and  manufacturing  developments 
greatly  reduced  the  size  and  increased  the  power  of  data  entry  terminals  to 
the  degree  that  intelligent  terminals  could  be  placed  directly  into  the  hands  of 
the  FEs.  While  the  use  of  handheld  terminals  had  a  number  of  associated 
problems  (they  required  FEs  to  remember  codes  due  to  the  limited  size  of  the 
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display  screen  and  placed  the  FE  in  a  data  entry  role),  data  entry  errors  could 
now  be  caught  at  the  source,  and  the  terminals  allowed  the  FE  to  communi- 
cate directly  with  the  main  data  storage  location.  Eventually,  a  major  benefit 
of  the  handheld  terminal  would  appear— the  ability  to  provide  two-way 
communication  between  the  FE  and  service  management. 

B.       CURRENT  FIELD  SERVICE  MANAGEMENT  SYSTEMS 

•  Currently,  the  basic  functions  of  a  field  service  management  system  are 
slanted  toward  traditional  business  needs: 

Call  handling. 

Dispatching. 

Parts  tracking  (including  use). 
Accounting  and  billing  functions. 

Limited  informational  capabilities  (e.g.,  customer  histories). 

•  As  stated  previously,  the  fundamental  activity  of  call  handling  and  dispatching 
has  been  a  cornerstone  of  automated  service  delivery  systems.  Efficient 
service  delivery  requires  the  following  activities  to  be  performed  in  a  timely 
manner: 

Initial  call  fielding. 

identification  of  the  equipment  at  the  site. 
Verification  of  the  contract. 
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Identification  and  recording  of  a  problem. 

Routing  of  the  call  to  the  appropriate  person/department. 

Calculating  and  comnnunicating  the  appropriate  response. 

Determination  of  the  appropriate  parts  and  repair  time. 

Parts  use. 

Call  closing. 

The  accomplishment  of  these  tasks  should  be  instantaneous  and  invisible  to 
the  customer.  Given  the  increased  requirement  of  users  for  virtually  100% 
system  availability,  increased  downtime  as  a  result  of  the  call  handling  and 
dispatching  function  is  unthinkable.  As  a  result,  the  concept  of  real  time 
informational  processing  became  the  goal  of  all  FSMS  activities. 

Typically,  the  size  of  the  service  organization,  along  with  (to  some  degree) 
the  organizational  structure  philosophy  of  the  corporate  entity,  determines 
whether  the  call  handling  point  be  a  centralized  (national)  toll-free  number,  a 
regional  toll-free  number,  or  a  local  (usually  non-toll-free)  number.  Size  or 
type  of  service  organization  does  not  always  determine  this  structure.  TRW 
and  Sorbus,  both  TPMs  similar  in  size,  use  centralized  and  regionalized 
systems  respectively,  with  similar  effectiveness.  What  is  most  important  is 
that  customers  perceive  fast  response  and  resolution  to  their  problem. 

With  that  priority  in  mind,  the  system  should  be  capable  of  determining 
existing  workloads  and  locations  of  available  resources  (FEs  and  spare  parts) 
to  assure  prompt  response  and  resolution  of  the  problem.  Again,  the  concept 
of  real  time  arises  since  an  FE  or  part  location  was  rarely  available 
immediately  in  a  paper-based  system. 
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Informational  functions  of  FSMS  systems  smoothed  the  transition  of  service 
both  internally  and  externally.  Installation  data  helped  determine  expertise 
needed,  configuration  status,  and  potential  problems  that  might  result  from 
compatibility  problems  (this  unfortunately  also  led,  in  some  cases,  to  "finger- 
pointing").  In  addition,  this  data  also  fed  equipment  reliablity  and  usage 
reports.  Contract  verification  data  helped  prioritize  calls  while  also  reducing 
problems  with  customers  who  would  m.ove  products  in  and  out  of  service 
coverage  (some  customers  would  only  contract  certain  products  and  try  to  get 
the  FE  to  service  noncontracted  equipment,  even  by  switching  boards  and 
components). 

As  suggested  above,  the  call  handling  and  dispatching  functions  of  an  FSMS 
system  created  additional  strength  of  automated  service  delivery—that  being 
informational  capabilities.  Analyzing  FE,  service  office,  or  overall  service 
staff  efficiency  became  possible  by  analyzing  call  open  and  call  close  data. 
Parts  use,  inventory  levels  needed,  and  product  serviceability  reports  are  just 
a  few  analyses  available. 

Furthermore,  the  accumulated  information  of  problems  and  their  resolutions 
became  a  useful  tool  in  future  problem  identification  and  resolution,  particu- 
larly to  those  organizations  who  took  advantage  of  the  real  time  benefits  of 
handheld  terminals.  Although  screen  size  limited  the  size  of  information 
transmitted,  coded  instructions  could  easily  be  transmitted  (and  monitored)  to 
the  FE  from  headquarters,  regional  support  centers,  or  other  FEs. 

Also  part  of  the  system's  capabilities  is  its  ability  to  automatically  begin 
escalation  procedures  after  a  predetermined  and  reasonable  period  of  time. 
Given  the  systems  data  base  of  historical  information  on  mean-time-to-repair 
(MTTRepair)  plus  prescribed  mean-time-to  respond  (MTTRespond)  that  is 
determined  by  system,  parts  availability,  etc.,  the  system  should  be  able  to 
easily  assure  both  prompt  response  to  ail  problems  and  reasonable  resolution 
times. 
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In  addition  to  the  service-related  functions  discussed  above,  current  FSMS 
systenns  also  manage  the  business  aspects  of  service,  including  cost  reports, 
P&L  analyses,  billing,  and  other  accounting  functions.  Again,  the  system 
should  be  able  to  easily  repair  such  reports,  given  that  all  service  data  is 
collected  and  stored  in  a  central  data  base  that  is  shared  and  accessed  by  all 
functions  of  the  FSMS  system. 

This  leads  to  the  final  requirement  of  current  FSMS  systems— that  the  system 
be  completely  integrated.  Furthermore,  the  system's  central  data  base  will  be 
accessed,  directly  or  indirectly,  by  three  sources  of  new  data— the  FE,  service 
management,  and  (indirectly)  the  customer.  Exhibit  III- 1  summarizes 
informational  flow  to  and  from  each  of  these  sources  and  the  FSMS  system. 

Breaking  down  this  informational  flow.  Exhibit  III-2  shows  the  interaction 
between  the  FE  and  the  system.  The  FE  opens  the  call  by  arriving  on-site, 
verifies  contract  confirmation  (while  the  system  should  perform  contract 
confirmation  prior  to  FE  dispatch,  it  is  still  necessary  for  the  FE  to  assure 
that  the  specific  failed  product  and  part  are  indeed  covered  by  contract), 
determines  parts  needed/used,  and  closes  call.  The  system  may  provide  the 
FE  with  product  information,  customer  history,  some  level  of  service 
instructions,  and  other  informational  needs  (e.g.,  messaging). 

Exhibit  111-3  shows  the  informational  flow  between  the  service  management 
and  the  system.  For  the  most  part,  information  flows  to  service  management 
in  the  form  of  accounting  information,  efficiency  reports,  parts  use,  etc.  On 
occasion,  management  might  supply  the  system  with  updated  or  new 
information  on  products. 

A  more  indirect  interaction  and  flow  of  information  between  the  customer 
and  the  system  is  shown  in  Exhibit  III-4.  The  FSMS  system  automatically  bills 
contract  customers  on  a  predetermined  basis  and  has  the  capabilities  to  bill 
noncontract  (T&M)  customers  for  both  labor  and  parts  use.    The  customer 
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EXHIBIT  III-1 


FLOW  OF  SERVICE  INFORMATION 


Handheld 


Terminal 


Parts 
Usage 


Product  Information 
Service  Instruction 


FSMS 


Invoice 


Accounting  Information 


Efficiency  Reports 


Parts  Usage 


Payment 
Feedback 


(  User  1 


FT01-4b 


-22- 


©1987  by  INPUT.  Reproduction  Prohibited. 


INPUT 


EXHIBIT  III-2 


INFORMATION  FLOW:    FE  TO/FROM  FSMS 
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EXHIBIT  III-3 


INFORMATION  FLOW:     FSMS  TO  MANAGEMENT 
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EXHIBIT  III-4 

INFORMATION  FLOW:     FSMS  TO  CUSTOMER 
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indirectly  updates  the  data  base  by  paying  the  bill.  A  rarely  used  aspect  of 
the  customer  system  interface  Is  the  systemized  extraction  of  customer 
feedback  through  the  system.  Customers  can  be  routinely  queried  concerning 
their  satifactlon  with  their  product  or  service. 

•  Exhibit  III-5  provides  an  overview  of  selected  packaged  FSMS  software  avail- 
able to  service  organizations.  This  list  Is  by  no  means  exhaustive;  rather,  It 
fairly  represents  the  most  popular  packages  on  the  market. 

•  it  should  be  noted  that  most  larger  service  organizations  have  developed  their 
own  FSMS  system  in-house,  as  will  be  shown  in  Chapter  IV.  Exhibit  III-6 
presents  the  advantages  and  disadvantages  of  packaged  FSMS  software 
systems  as  compared  to  in-house  systems.  Perhaps  the  most  siglficant  benefit 
of  in-house  developed  systems  (other  than  the  obvious  advantage  of  customi- 
zation) is  the  competitive  edge  perceived  by  service  organizations  toward 
their  own  system  (TRW,  for  example,  regularly  offers  tours  of  its  facilities). 

C.       HANDHELD  TERMI^4ALS 


•  As  Indicated  above,  the  ability  to  communicate  quickly  and  efficiently 
became  a  key  objective  in  maximizing  the  amount  of  time  that  the  FE  is 
generating  revenue.  One  way  of  meeting  this  objective  was  the  adoption  of 
state-of-the-art  portable  terminals.  Not  only  have  these  terminals  Improved 
FE/management  communications,  but  they  also  have  Improved  the  EE's  ability 
to  diagnose  and  effect  repairs. 

•  Basically,  a  handheld  terminal  provides  the  following  capabilities  to  an  FE: 

Small  size,  usually  about  the  size  of  a  cellular  telephone. 
Light  weight,  usually  about  a  pound. 
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EXHIBIT  III-5 

REPRESENTATIVE   FSMS  SOFTWARE  PRODUCTS 
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EXHIBIT  III-5  (cont.) 


REPRESENTATIVE   FSMS  SOFTWARE  PRODUCTS 
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EXHIBIT  III-6 

ADVANTAGES/DISADVANTAGES  OF 
FSMS  SOFTWARE 
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Compact,  yet  full-featured  keyboard,  usually  with  special  function 
keys. 

Limited  display  with  scrolling  capabilities. 

Internal  memory  with  plug-in  memory  expansion  capabilities. 

Communications  capabilities,  either  direct  modem  or  acoustic-coupled. 

Future  expansion  capabilities,  e.g.,  printers,  wand  readers,  etc. 

As  discussed  previously  in  Section  A  of  this  chapter,  handheld  terminals  have 
replaced  paper-based  and  telephone/radio-based  dispatching  activities,  with 
dramatic  improvement  in  responsiveness  and  repair  times.  Furthermore, 
handheld  terminals,  along  with  other  service  developments  (such  as  increased 
modularity  of  computer  design),  have  helped  increase  in-field  performance  of 
the  engineering  staff,  helping  to  reduce  labor  costs  and  increase  service 
profitability.  In  addition,  use  of  these  terminals  reduces  other  service  costs, 
such  as  dispatching  force  needed,  parts-needed  return  trips,  and,  to  a  limited 
degree,  no-fault-found  calls.  In  the  near  future,  handheld  terminals  will  have 
a  more  direct  affect  on  service  delivery  by  adding  to  their  diagnostic 
capabilities. 

One  of  the  first  companies  to  realize  the  benefits  of  handheld  terminals  was 
IBM  with  its  Digital  Communications  System.  The  system  is  built  around 
four-inch  by  eight-inch,  28  ounce  terminals  that  are  linked  by  an  800  MHZ 
two-way  radio  network.  This  system  replaced  a  more  cumbersome  process  in 
which  a  user  called  a  coordination  center,  which  had  to  locate  and  page  an 
available  local  field  representative,  who  would  have  to  find  a  phone  to  call  the 
coordination  center  to  take  the  call. 
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•  Instead,  service  calls  can  be  directly  sent  to  the  service  representative  along 
with  any  pertinent  site,  customer,  or  service  information.  Furthermore,  the 
terminals  can  be  used  by  service  representatives  to  request  additional 
information  from  support  centers  or  even  other  service  representatives  in  the 
field.  Service  representatives  use  the  system  to  order  needed  parts  and  to 
report  parts  use,  thus  speeding  parts  tracking  and  inventory  control.  Field 
management  can  use  the  system  to  plan  and  coordinate  meetings  and  can 
query  service  representatives  about  calls  in  progress  and  past  calls. 

•  A  number  of  companies  have  entered  the  handheld  terminal  market.  Exhibit 
111-7  provides  a  representative  sample  of  leading  vendors  and  their  products. 
Note  that  most  provide  similar  functionality  with  similar  dimensions  (the  main 
difference  between  these  products  and  the  IBM  portable  terminal  is  the 
physical  orientation— IBM's  width  is  eight  inches,  while  the  competitions' 
length  is  eight  inches). 

•  Future  terminals  will  add  greater  communications  and  diagnostic  capabili- 
ties. For  example,  a  few  systems  currently  offer  bar  code  reader  capabilities; 
however,  the  very  nature  of  computer  boards  and  components  prohibit  the  use 
of  present  "wand"  readers  that  might  touch  the  board  or  component.  Future 
readers  will  be  laser-based,  allowing  the  FE  to  read  the  ID  code  without 
physically  touching  the  part.  Scanning  will  greatly  reduce  the  time  necessary 
to  enter  the  part  number  into  the  terminal. 

D.       REMOTE  DIAGNOSTiCS/SUPPORT 


•  Remote  diagnostics  is  defined  as  the  ability  to  gain  access  to  a  computer  from 
a  point  physically  distant  from  the  computer  in  order  to  perform  problem 
determination  activities.  Typically,  remote  diagnostic  activities  were  limited 
to  telephone  (dial-up)  diagnosis  performed  by  technical  support  personnel  at 
the  computer  vendor's  regional  (or  in  some  cases  national)  remote  support 


-31  - 

©1987  by  INPUT.  Reproduction  Prohibited.  INPUT 


( 

EXHIBIT  III-7 
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centers,  usually  as  an  aid  to  on-site  service  personnel  while  the  FE  was  on-site 
and  also  usually  in  response  to  the  FE's  request  for  assistance. 

Early  remote  diagnostics  was  faced  with  opposition  from  a  number  of 
sources.  Field  engineers  felt  threatened  by  the  new  technology,  fearing  that 
automation  would  eventually  replace  their  jobs.  Many  users  were  also 
confused  and  hesitant  to  allow  remote  diagnostics  for  a  number  of  reasons: 

Confusion  over  remote  pricing,  since  some  vendors  offered  discounts 
for  use  of  remote  diagnostics,  others  charged  premiums  for  use  of 
remote  diagnostics,  and  still  others  essentially  charged  premiums  by 
requiring  users  to  purchase  special  modems  and  software  to  run  the 
diagnostics.  The  users  recognized  that  vendors  stood  to  gain  from 
remote  diagnostics  and  could  not  see  why  users  should  have  to  pay  for 
the  implementation  of  the  technology. 

Fear  about  the  security  of  data,  even  in  cases  where  remote  access 
stopped  at  the  controller  level  of  the  user's  system  and  even  after 
vendors  would  offer  to  sign  statements  defining  and  limiting  use  and 
access  to  the  system. 

Concern  about  losing  the  "warm  fuzzies"  associated  with  on-site 
service  visits.  Although  users  would  be  shown  the  increased  system 
availability  benefits  of  remote  diagnostics,  they  would  still  fear  a 
decline  in  overall  support  if  remote  diagnostics  was  adopted. 

Eventually,  increased  user  requirement  for  100%  system  availability  coupled 
with  a  realization  by  users  that  remote  diagnostics  activities  could  help 
vendors  hold  down  service  prices  overcame  user  opposition  to  remote 
diagnostics.  Users  saw  improvements  in  MTTRepair,  reductions  in  no-fault- 
found  calls  and  return  trips  for  parts,  and  increases  in  overall  system  avail- 
ability. Furthermore,  remote  diagnostics  became  almost  invisible  to  users, 
since  newer  systems  would  arrive  with  the  technology  already  built-in. 
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Vendors  also  saw  tremendous  benefits  in  the  implementation  of  remote 
diagnostics,  all  at  a  time  when  service  costs  are  coming  under  increased 
observation.  The  technology  had  evolved  to  a  point  that  implementation  costs 
no  longer  prohibited  the  use  in  systems  other  than  the  large  mainframes. 
Furthermore,  remote  diagnostics  reduced  the  labor-intensiveness  of  providing 
hardware  support  by  reducing  the  number  of  on-site  calls  necessary. 

Remote  diagnostics  also  relieved  service  organizations  of  personnel  short- 
ages. Prior  to  remote  technology,  service  organizations  had  to  compete  for 
trained  field  support  personnel.  This  competition  was  increased  as  the  third- 
party  maintenance  industry  took  off  in  the  late  1970s  and  early  1980s. 
Increased  use  of  remote  diagnostics  along  with  increased  use  of  modular 
computer  design  allowed  service  organizations  to  use  engineers  with  less 
experience,  increasing  the  available  supply  of  service  personnel  and  reducing 
the  overall  service  salary  level. 

Almost  all  computer  manufacturers  have  incorporated  remote  diagnostic 
capabilities  into  their  new  computer  systems;  however,  industry  giant  IBM  is 
thought  to  be  the  first  to  incorporate  remote  diagnostics  into  its  service 
dispatching  system.  In  1978,  IBM  introduced  the  first  remote  support  center 
for  the  8100  (small)  Information  System,  and  in  1979  furthered  its  involvement 
with  the  4300  family  of  minicomputers. 

Currently,  IBM's  newest  mainframe  product,  the  3090  family,  utilizes  a 
separate  diagnostics  and  support  processor  (the  3092  Processor  Control)  that 
monitors  all  key  aspects  of  the  3090's  operation,  including  power,  cooling, 
circuits,  and  all  field  replaceable  units  (FRUs),  such  as  thermal  conduction 
modules  (TCMs),  boards,  cards,  and  cables.  Error  and  system  status  informa- 
tion is  stored  on  a  pair  of  dedicated  3370  disk  drives  that  can  be  accessed 
remotely  from  regional  support  centers.  Support  tecnicians  at  the  support 
centers  can  instruct  the  system  to  perform  additional  diagnostic  routines,  if 
necessary.  The  system  can  also  create  a  log  of  all  problems,  as  well  as 
reports  on  all  "unrecoverable"  failures. 
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Another  company  that  has  advanced  the  use  of  remote  diagnostic  (and 
support)  technology  is  Stratus  Computer,  Inc.,  a  manufacturer  of  fault- 
tolerant  computer  systems.  Stratus'  strategy  slightly  differs  from  standard 
industry  philosophy  of  service  by  emphasizing  user  involvement  in  service, 
augmented  by  heavy  reliance  on  remote  support  (Stratus  dubs  this  approach 
RAU,  short  for  "remote  support,"  "automatic  dial-out,"  and  "user-service- 
ability"). Stratus  operates  two  Customer  Assistance  Centers  (CACs) 
domestically  which  are  connected  to  customer  sites  and  each  other  via  a  dial- 
up  Remote  Support  Network  (RSN).  These  support  centers  (which  are  not 
manned  around-the  clock;  off-hour  coverage  is  handled  by  paged  personnel), 
can  receive  support  communication  automatical  from  the  system  or  by 
customer-instigated  communication.  CAC  personnel  then  can  perform  remote 
diagnostics,  downline  transmit  files  with  new  code  (for  software  problems),  or 
respond  to  electronic  mail-transmitted  requests  for  support  of  a  less  urgent 
basis. 

Another  strength  of  Stratus'  system  is  call  management,  which  is  handled 
through  the  RSN  and  logged  at  each  CAC.  Depending  on  the  problem  (as 
diagnosed  remotely),  either  a  replacement  part  is  shipped  overnight  or  a 
Stratus  engineer  is  dispatched  to  provide  on-site  support.  Since  Stratus 
systems  are  designed  using  redundant  architecture,  immediate  response  times 
are  almost  always  unnecessary. 

A  further  benefit  of  Stratus'  support  strategy  is  that  the  reduced  cost  of 
providing  support  is  transferred  to  the  user.  Users  can  opt  for  any  of  three 
service  packages  at  various  prices: 

Users  who  agree  to  perform  most  routine  part  replacements  pay  3.5% 
of  list  price  per  year. 

Users  who  agree  to  swap  out  "easy"  parts  (PCBs,  terminals,  etc.)  but 
leave  more  complex  parts  (disks,  tapes,  power  supplies,  etc.)  to  Stratus 
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pay  6.5%  of  list.  Stratus  reports  that  90%  of  all  Stratus  users  opt  for 
this  "co-active"  service  arrangement. 

Users  who  prefer  to  avoid  participation  in  support  can  opt  for 
traditional  vendor-supplied  maintenance  at  10.5%  of  list. 

•  The  use  of  remote  support  has  already  shown  tangible  improvements.  IBM,  for 
example,  has  found  that  84%  of  incoming  calls  for  software  support  are  now 
capable  of  being  handled  over  the  telephone  rather  than  on-site  and  that  most 
of  these  are  solved  in  less  than  30  minutes.  Data  General,  another  company 
that  has  successfully  incorporated  remote  support  into  its  high-end  mini- 
computer line,  reports  20-25%  decreases  in  service  incidents  while  solving 
75%  of  problems  over  the  phone.  Data  General  lists  additional  benefits  of 
remote  support: 

Reduced  direct  labor  costs  as  more  expensive  on-site  FEs  have  been 
replaced  with  remote  support  center  technicians. 

Improved  response  times  to  customers,  many  of  whose  problems  can  be 
solved  instantly  by  the  system  or  over  the  phone. 

Better  management  of  spares  with  better  accessibility  since  FEs  are 
now  freed  from  having  to  carry  all  possible  spares  with  them. 

Better  time  management  of  service  staff  through  reduction  of  no- 
fault-found  and  spare-part-needed  calls. 

Decreased  cost  of  outfitting  FEs,  not  only  with  spares,  but  also  with 
diagnostic  and  service  tools  and  equipment. 

Reduced  training  costs,  allowing  more  focused  training  on  specific 
systems  and  routines. 
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USER  REQUIREMENTS  FOR  AUTOMATED  SERVICE  DELIVERY 


A.  OVERVIEW 

•  In  this  chapter,  the  results  of  detailed  interviews  with  the  service  organiza- 
tions from  both  manufacturers  and  independent  third-party  maintenance 
companies  are  analyzed.  The  focus  of  this  sample  is  weighted  toward  larger 
service  organizations  (the  smallest  respondent  was  Total  Technical  Services, 
an  $18  million  TPM),  accounting  for  the  preponderance  of  in-house  developed 
systems  in  the  sample.  However,  the  functional  needs  of  these  larger  service 
organizations  are  no  different  than  smaller  organizations,  other  than  the  scale 
of  their  resource  management  requirements  and  their  ability  to  allocate 
costs.  Hence,  the  sample  reflects  the  needs  of  all  service  organizations.  The 
report  will  attempt  to  comment  on  any  differences  where  size  or  type  of 
service  organizations  might  cause  some  variance. 

•  Exhibit  IV- 1  graphically  demonstrates  the  overwhelming  preponderance  of  in- 
house  developed  systems,  used  by  14  out  of  the  16  service  organizations 
surveyed  (88%).  The  reasons  behind  this  include: 

The  size  and  scope  of  the  information  handling  needs. 

The  ability  to  customize  the  system  to  each  company's  precise  needs. 

The  importance  of  the  system  as  a  "competitive  edge." 
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EXHIBIT  IV-1 


SOURCE  OF  FSMS 


Purchased  from 
Software  Vendor 


Sample  =  16 


FT01-12b 
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Smaller  service  organizations  would  be  much  more  likely  to  use  "packaged" 
software  solutions.  First  of  all,  their  information  handling  needs  (in  terms  of 
customers  and  FEs)  would  be  smaller  in  scale  to  the  size  of  their  company.  In 
addition,  their  financial  resources  usually  would  be  insufficient  to  warrant  in- 
house  development  of  such  a  system,  making  the  packaged  system  a  more 
economical  solution  (a  typical  comment--"Why  reinvent  the  wheel?"). 

As  smaller  service  organizations'  needs  grow,  packaged  systems  usually  allow 
some  level  of  customization  as  most  packages  available  are  modular  in 
nature.  When  a  service  organization  wants  to  add  a  new  function  (e.g., 
accounting),  all  they  need  to  do  is  add  that  module. 

Exhibit  IV-2  demonstrates  that  most  FSMS  systems  are  located  at  centralized 
locations,  which  is  understandable  due  to  the  fact  that  most  users  of  the 
information  provided  by  the  system  would  be  at  the  headquarters  level. 

Not  surprisingly,  almost  all  service  organizations  place  the  highest  require- 
ment on  traditional  service  management  functions,  as  shown  in  Exhibit  IV-3, 
specifically  parts  tracking,  dispatching,  and  informational  (e.g.,  customer 
histories).  Also  not  surprisingly,  most  service  organizations'  systems  satisfy 
these  functional  requirements. 

What  is  surprising  is  the  low  requirement  that  service  organizations  place  on 
accounting  functions,  such  as  billing.  This  low  requirement  was  supported  by 
the  fact  that  only  56%  of  the  responding  service  organizations  receive 
accounting  support  from  their  system.  This  low  use  of  accounting  functions  is 
confusing,  given  the  large  (89%)  number  of  organizations  that  use  their  system 
to  maintain  customer  histories.  What  this  suggests  is  that  service  organiza- 
tions prefer  to  leave  accounting  and  billing  functions  outside  of  their 
responsibility. 
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EXHIBIT  IV-2 


LOCATION  OF  FSM  SYSTEM 
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EXHIBIT  lV-3 


FSMS  FEATURE  PRIORITIES 
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•  The  sample  also  placed  low  requirement  on  manpower  studies;  however, 
almost  three-quarters  of  the  respondents  reported  that  they  received  some 
form  of  manpower  report  from  their  system. 

•  The  results  of  this  question  reflects  the  limited  integration  of  service 
management  functionality  present  in  today's  systems.  While  most  systems 
provided  logistic  support  (dispatching,  call  handling,  parts  tracking,  and 
inventory  control),  only  half  (56%)  incorporated  accounting  and  almost  none 
(28%)  provided  remote  support  capabilities.  These  functions  undoubtedly  are 
automated  in  all  of  these  companies  (assuming,  of  course,  that  the  company 
has  remote  support  capabilities);  the  important  point  is  that  the  use  of 
multiple  systems  (and  presumably  multiple  data  bases)  does  not  maximize 
efficiency. 

B.       CASE  STUDIES 

•  In  the  following  section,  INPUT  will  present  case  studies  of  selected  service 
organizations  and  their  experiences  and  needs  concerning  automated  service 
delivery.  The  six  companies  were  selected  on  the  basis  of  the  uniqueness  or 
extent  of  their  automation. 

I.        AMDAHL  CORPORATION 

•  Amdahl  is  a  leading  vendor  of  IBM  plug-compatible  mainframes  and  related 
products,  having  installed  its  first  system  (470  V/6)  in  1975.  In  1986,  Amdahl 
sales  were  $966  million,  with  an  estimated  $200  million  coming  from  customer 
services.  Amdahl  employs  750  hardware  and  software  support  engineers  in  the 
U.S. 

•  Service  is  delivered  to  Amdahl  contract  customers  around-the-clock,  seven 
days  a  week.   While  Amdahl  does  not  contractually  guarantee  response  times, 

i 
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INPUT  studies  demonstrate  that  Amdahl  users  report  reponse  times  of  one 
hour  or  less.  Much  of  Amdahl's  success  is  attributed  to  remote  support 
delivered  through  Amdahl's  worldwide  remote  support  network  called  Amdahl 
Diagnostic  Assistance  Network  (AMDAC).  AMDAC  provides  hardware  and 
software  support  to  users  of  all  Amdahl  equipment.  In  addition,  Amdahl 
systems  have  a  built-in  console  processor  that  facilitates  on-site  diagnosis  of 
system  problems. 

Amdahl  currently  runs  its  current  (in-house  developed)  system  on  an  Amdahl 
5890  system  located  at  a  central  location.  The  system  does  not  provide 
dispatching  and  call  handling  (a  separate  manual  system  satisfies  that  need) 
but  does  provide  parts  tracking,  customer  and  product  histories,  invoicing  and 
accounting  capabilities,  manpower  efficiency  reports,  messaging,  and  training 
instructions  to  the  remote  support  technician. 

Amdahl  uses  a  separate  system  running  on  a  5890  to  automate  remote  support 
and  hopes  to  link  all  systems  within  the  next  two  years.  Amdahl's  long-range 
goal  is  to  have  a  single  integrated,  closed-loop  system  that  tracks  and  stores 
service  information,  accessible  by  the  FE  through  data  collection  terminals 
with  intelligence  at  a  higher  level  than  current  handheld  terminals.  As  with 
many  companies,  Amdahl's  goal  is  to  move  from  "reactive"  maintenance  to 
"predictive"  support. 

It  should  be  noted  that  Amdahl's  selection  of  parts  handling  as  a  starting  point 
for  service  automation  is  not  surprising  given  the  extremely  high  cost  of 
replacement  parts  of  its  systems.  Amdahl  also  makes  use  of  overnight  express 
companies  for  the  distribution  (and,  in  effect,  storage)  of  these  high-priced 
spare  parts.  It  becomes  most  critical  for  a  company  like  Amdahl  to  assure  the 
most  effective  use  and  storage  of  these  critical  spares. 
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DATA  GENERAL  CORPORATION 


Data  General  (DG)  maufacturers  a  wide  range  of  products  in  the  small 
systems  market,  ranging  from  low-end  laptop  micros  up  to  high-end  super- 
minicomputers (such  as  the  new  MV/20000).  Total  revenue  for  1986  was  $1.3 
billion  (up  2%  over  1985),  with  service  revenues  of  $399.7  million  (up  22%). 
Weak  sales  forced  DG  to  make  a  number  of  organizational  moves,  including 
layoffs  and  consolidation  of  a  number  of  product  and  support  groups.  Field 
engineering  was  not  left  untouched,  as  all  North  American  hardware  and 
software  phone  support  was  consolidated  at  the  Norcross  (GA)  facility.  Depot 
repair  and  logistics  functions  were  also  consolidated  at  the  Fountain  (CO) 
location. 

As  might  be  expected  from  a  company  with  a  wide  range  of  products,  DG 
offers  support  services  to  its  users  in  a  wide  range  of  offerings.  Customers 
can  receive  on-site  support  (dispatched  from  DG's  centralized  facility  in 
Georgia)  with  their  choice  of  9-  through  24-hour  coverage,  remote  support  (on 
newer  high-end  systems),  depot  service  (from  DG's  new  Colorado  facility),  and 
time-and-material  service.  DG  provides  on-site  software  support  to  users 
under  contract  in  addition  to  telephone  access  to  software  problems  data 
bases. 

DG  currently  uses  two  separate  service  automation  systems,  both  of  which 
were  developed  in-house.  The  first,  Customer  Dispatch  System  (CDS),  handles 
all  call  handling  and  dispatching  functions  as  well  as  messaging,  product 
information,  manpower  efficiency  reports,  invoicing,  and  P&L  reports.  A 
second  companion  program,  FACTS,  handles  all  field  accounting  of  spare  parts 
use  and  location.  There  is  no  link  currently  between  the  two  systems; 
however,  DG  hopes  to  integrate  the  two  systems  within  the  next  two  years. 

DG  also  hopes  to  add  a  problems  data  base  accessible  by  the  field  engineer 
within  the  next  few  months.  Currently,  a  different  system  provides 
computer-aided  instruction  (CAl)  to  the  field  support  staff  to  assist  with 
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training,  in  addition,  DG  is  implementing  a  new  contracts  module  to  the 
system  within  the  next  month. 

DG,  along  with  most  other  service  organizations,  sees  the  growing  importance 
of  gaining  tighter  controls  over  the  costs  involved  with  delivering  service  to 
its  customer  base.  DG  recognizes  the  decline  in  the  labor  content  of  service 
and  the  increase  in  the  costs  of  parts.  However,  DG  also  emphasizes  the 
dispatching  and  call  handling  functions  within  its  systems,  since  that  is  the 
first  part  of  service  that  a  user  sees. 

In  the  future,  DG  hopes  to  implement  a  real  time  system  that  provides 
machine-to-machine  interface.  The  system  will  collect  information  about 
performance,  analyze  data,  identify  exceptions,  and  report  these  exceptions 
to  the  service  organization.  Along  with  this  emphasis  on  predictive  service, 
DG  sees  the  future  system  to  provide  more  preventive  support  with  fault 
isolation  capabilities  as  well  as  fault  discovery.  - 

DATASERV  COMPUTER  MAINTENANCE 

Dataserv  Computer  Maintenance,  a  division  of  Dataserv,  Inc.,  is  a  $50  million 
third-party  maintenance  (TPM)  that  specializes  in  the  maintenance  of  large 
IBM  systems,  as  well  as  the  sale  of  spares  and  refurbishment  services. 
Atlanta-based  Bell  South  Corporation,  a  regional  Bell  operating  company, 
recently  announced  plans  to  acquire  Dataserv  Computer  Maintenance 
division's  parent  for  a  reported  $96.5  million  in  stock. 

Dataserv  offers  service  out  of  32  cities  in  the  U.S.,  dispatching  an  estimated 
350-400  engineers  on-site  to  customers'  locations  (70%  of  Dataserv's 
customers  receive  on-site  maintenance  service).  Dataserv  dispatches  these 
engineers  from  a  centrally  located  (Edan  Prairie,  MN)  dispatch  center,  using  a 
purchased  system  from  Soft  Solutions  (Minnetonka,  MN).  The  system,  called 
Field  Facts,  can  support  up  to  500  engineers;  nonetheless,  Dataserv  felt  it 
necessary  to  modify  the  system  for  its  own  use.  The  system  currently  runs  on 
Dataserv's  IBM  System  36  minicomputer. 
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The  system  now  provides  dispatching  and  call  managennent,  messaging,  part 
management,  site  histories,  product  information,  invoicing  and  other 
accounting  functions,  and  manpower  efficiency  reports.  A  separate 
accounting  system  provides  P&L  reports. 

As  a  TPM,  remote  support  functionality  is  currently  not  a  high  priority  at 
Dataserv.  Instead,  Dataserv  places  the  highest  requirement  on  more  tradi- 
tional service  management  functions,  such  as  dispatching,  parts  tracking,  and 
accounting.  Dataserv  hopes  to  integrate  the  P&L  function  into  its  system  in 
the  near  future. 

Dataserv  is  typical  of  medium  size  TPMs.  It  has  a  growing  need  to  efficiently 
track  resources  (manpower,  spares),  yet  insufficient  resources  (money)  to 
develop  a  system  completely  in-house.  As  a  result,  a  service  organization 
such  as  Dataserv's  (or  First  Data  Resources,  which  chose  a  packaged  system 
(Super  Service)  from  Pacific  Data  Science  Corporation  (Los  Angeles,  CA)  to 
supplement  one  purchased  from  McDonnell  Douglas  called  Sitrack  System) 
looks  to  an  existing  solution  to  their  automation  need.  And  as  the  complexity 
of  resource  handling  needs  grows,  the  service  organization  can  either  add 
additional  functionality  (if  the  product  is  modular  in  design),  customize  the 
package  through  additional  programming  (either  in-house  or  in  conjunction 
with  the  software  vendor),  or  replace  the  package  completely  with  their  own 
in-house  solution. 

DIGITAL  EQUIPMENT  CORPORATION 

Digital  Equipment  Corporation  (DEC)  is  a  manufacturer  of  a  wide  range  of 
small  systems,  ranging  from  microcomputers  to  clustered  superminicomputers 
(such  as  the  new  VAX  8XXX  series)  that  compete  with  traditional  main- 
frames. While  many  companies  have  struggled  in  the  recent  slump  in  the 
computer  industry,  DEC  has  flourished  with  total  revenue  growth  of  13.5% 
(1986  revenues  were  $7.6  billion,  up  from  $6.9  billion),  while  service  revenue 
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grew  to  $2.6  billion  (up  22%  over  1985).  DEC  has  relied  on  developments  in 
its  VAX  lines,  as  well  as  IBM's  difficulties  in  the  small  systems  market  (where 
DEC'S  compatibility  within  its  own  product  line  is  seen  as  a  major  advantage). 

DEC  consolidated  hardware  and  software  support  functions  by  combining 
Software  Products  Services  with  the  Field  Service  division.  This  consolidation 
is  shown  in  the  Customer  Support  Center  (CSC),  opened  in  Colorado  in  April 
of  1986.  The  center  (one  of  14  worldwide)  is  responsible  for  remedial  and 
advisory  support  for  both  hardware  and  software  customers  throughout  the 
U.S.  During  1986,  the  CSC  fielded  over  one  million  calls  from  56,000 
customer  contacts. 

The  CSC  runs  three  shifts  per  day  (two  shifts  on  weekends)  providing  around- 
the-clock  coverage  from  130  hardware  specialists,  300  software  specialists, 
and  110  customer  response  representatives.  Services  provided  to  DEC 
customers  include  system  problem  analysis,  preventive  hardware  services, 
advisory  software  services,  remote  software  remedial  support,  network 
monitoring  and  support,  DEC  support  remote  delivery,  and  Digital  Software 
Information  Network  (a  problems  data  base),  also  known  as  DSIN. 

The  CSC  also  provides  a  wide  range  of  services  to  internal  DEC  service 
employees,  such  as  remote  hardware  support  to  FEs,  technical  backup  to 
hardware  engineers  and  software  support  specialists  in  the  field  and  at  DEC 
support  locations,  remote  sales  support.  Software  Performance  Report  (SPR) 
screening,  and  library  screening. 

DEC'S  development  of  automated  service  delivery  is  also  demonstrated  in  its 
use  of  remote  diagnostics  and  support  delivery.  All  VAX  systems  can  run 
diagnostics  through  the  VAX  Integrity  Monitoring  System  (VAXSIM),  which 
allows  predictive  maintenance  by  monitoring  system  performance,  catching 
and  storing  intermittent  and  more  critical  system  interruptions  and  signalling 
before  threshhold  levels  occur.  All  VAX  users  receive  this  support  (in  fact,  a 
user  pays  a  15%  surcharge  to  not  run  remote  support). 
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DEC  has  also  developed  an  artificial  intelligence  (A!)  tool  for  tracking  and 
interpreting  failure  data  called  Standard  Package  for  Error  Accounting  and 
Reporting  (SPEAR).  This  tool  provides  an  analysis  of  the  system  based  on  a 
data  base  of  potential  problems  and  their  indicators  and  provides  to  the 
support  staff  three  potential  problems,  ordered  by  the  degree  of  likelihood. 
Again,  the  basis  of  this  system  is  to  provide  fault  identification  prior  to 
catastrophic  failure,  allowing  scheduled  replacement  of  the  problem  hardware 
or  software. 

DEC  also  utilizes  a  problems  data  base  known  as  STARS,  which  contains  over 
11,000  technical  articles  about  DEC  hardware  and  software  products, 
accessible  by  DEC  support  personnel,  and,  at  a  reduced  level,  to  users  through 
DISEN. 

The  goal  of  service  automation  at  DEC  Is  to  provide  "predictive"  service  and 
support  to  a  customer  base  that  Is  demanding  less  downtime  on  Increasingly 
complicated  systems  (and  networks  of  systems).  Parts  are  becoming  Increas- 
ingly expensive,  and  with  rapidly  decreasing  product  life  cycles  (In  the  past, 
product  life  cycles  were  3-5  years,  now,  they  are  18  months,  and  soon  they 
will  be  12  months  or  less),  the  need  to  control  costs  Is  an  extremely  high 
priority.  This  priority  Is  further  illustrated  by  the  change  in  cost  structure  at 
DEC: 

In  1980,  labor  (and  associated  overhead)  represented  49%  of  all  costs, 
with  the  remaining  51%  coming  from  materials  (and  their  associated 
overhead). 

In  1985,  labor  shrank  to  40?o,  while  materials  grew  to  60%. 

By  1990,  labor  is  expected  to  shrink  to  33%,  while  materials  will  grow 
to  67%. 
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STRATUS  COMPUTER,  INC. 


Stratus  is  a  manufacturer  of  fault-tolerant  computer  systems,  attractive  to 
those  with  extremely  high-system  availability  requirements.  The  basic  design 
involves  multiple  processors  and  self-run  diagnostic  routines  that  identify 
potential  and  real-system  errors  and  automatically  switch  to  a  back-up 
device,  hence  achieving  fault  tolerance. 

Stratus  has  been  shipping  products  since  1982  and  has  grown  to  become  a  $125 
million  company  in  1986,  second  only  to  Tandem  in  the  fault-tolerant 
market.  It  should  be  noted  that  IBM  markets  a  Stratus  system  as  its 
System/88. 

Obviously,  the  degree  of  fault-tolerance  at  Stratus  affects  the  service 
delivery  for  users.  Stratus  offers  three  low-cost  service  offerings  made 
possible  by  the  system's  basic  design  and  the  degree  of  remote  support 
implemented  by  Stratus.  Users  can  opt  for  various  levels  of  "co-active" 
support  at  contract  prices  that  range  from  3.5%  to  10.5%  of  system  purchase 
price,  depending  on  the  amount  of  customer  and  vendor  involvement. 

Even  though  fault-tolerance  lessens  the  burden  on  the  support  organization,  at 
least  in  terms  of  response  and  repair  times,  Stratus  recognizes  the  need  to 
efficiently  manage  resources,  particularly  those  that  involve  spare  parts. 
Stratus  developed  its  own  system  in-house  that  handles  dispatching  and  call 
handling,  spare  parts  tracking,  customer  and  product  histories,  and  customer 
billing.  Stratus  hopes  to  add  a  customer-accessible  problems  data  base  within 
the  next  two  to  three  months. 

Remote  support  and  implementation  are  highlighted  in  the  system,  running  on 
all  systems  locally  yet  controlled  from  Stratus'  central  location.  Stratus 
placed  the  highest  priorities  on  remote  support,  parts  tracking,  and  product 
information  data  bases. 
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•  Stratus  Is  moving  toward  systems-run  support  Implementation,  with  the 
systems  becoming  Increasingly  Involved  in  failure  identification,  isolation,  and 
correction.  Stratus  also  sees  the  role  of  the  user  increasing  in  the  support  of 
their  own  systems.  Users  will  become  increasingly  Involved  In  the  replace- 
ment of  boards  and  subassemblies.  The  role  of  the  FE  will  then  evolve  to  that 
of  a  "coordinator,"  handling  the  customers  needs  by  assuring  that  the  proper 
parts  and  technical  assistance  are  available. 

6.        SUN  MICROSYSTEMS,  INC. 

•  Sun  Microsystems  is  a  leading  supplier  of  32-bit  workstations  to  the  engi- 
neering, scientific,  and  technical  markets.  In  June  1986,  Sun  established 
Customer  Service  as  a  separate  division,  doubling  the  number  of  on-site  field 
support  staff  (from  50  to  100)  and  increasing  the  number  of  sales  and  support 
locations  by  1 2. 

•  Each  support  location  maintains  a  certain  level  of  spares;  however,  the 
central  service  location  in  Milpitas  (CA)  acts  as  the  national  parts  depot.  The 
company  currently  uses  ASK  Computer's  MANMAN/SERVICEMAN  service 
management  software  system  running  on  a  HP  3000  located  at  the  Milpitas 
location.  SERVICEMAN  provides  call  handling  and  dispatching,  parts  tracking 
and  inventory,  and  customer  and  product  histories.  SERVICEMAN  can  run  as 
a  standalone  product  (Sun  uses  It  as  such);  however,  the  program  was  designed 
to  run  best  as  an  integral  part  of  ASK's  MANMAN  integrated  manufacturing 
software  system.  Therefore,  such  functions  as  billing  (which  requires 
interface  with  MANMAN/OMAR)  and  accounting  (which  requires  Interface 
with  MANMAN/GL)  are  not  handled  by  SERVICEMAN. 

•  Thus,  Sun's  level  of  satisfaction  with  SERVICEMAN  is  diminished  by  the 
perceived  lack  of  "completeness"  of  functionality.  As  a  result.  Sun  Is 
currently  developing  a  system  In-house  that  will  provide  a  more  complete 
FSMS  solution  to  Its  needs.  A  primary  focus  of  the  system  will  be  to  better 
manage  the  "business"  aspects  of  service,  specifically  P&L  control,  invoicing, 
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and  accounting  reporting.  Furthermore,  Sun  recognizes  that  its  needs  are 
increased  as  they  expand  their  service  coverage. 

in  the  long  term,  Sun  hopes  to  increase  the  automation  of  service  delivery  by 
building  on  its  development  of  local  and  remote  diagnostics.  One  specific 
long-range  goal  is  to  implement  use  of  remote  (handheld)  terminals  for  call- 
close  purposes. 
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V        CONCLUSIONS  AND  RECOMMENDATIONS 


A.       THE  "IDEAL"  SYSTEM 


•  When  building  a  "wish  list"  of  features  and  functionality  desireable  in  a 
"perfect"  automated  service  system,  it  would  be  too  easy  to  fall  victim  to 
"gee  whiz"  technology  and  "pie-in-the-sky"  goal-setting.  Instead,  it  is  the 
objective  of  this  section  to  present  in  principle  a  system  that  is  available 
today  without  stretching  the  limits  of  currently  available  technology,  keeping 
in  mind  the  basic  strategic  thrust  of  providing  service  efficiently  and 
effectively  in  such  a  manner  that  meets  or  exceeds  customer  needs  while  still 
satisfying  corporate  profit  goals.  Exhibit  V-l  summarizes  such  a  system. 

I.        FIELD  SERVICE  MANAGEMENT  SYSTEMS 

•  Currently  available  software/turnkey  systems  designed  to  automate  basic 
service  management  are  extremely  capable  already.  Most  large  organizations 
prefer  to  use  their  own  in-house  developed  systems;  however,  packaged  and 
in-house  systems  are  relatively  similar  in  design  and  functionality: 

Almost  all  systems  provide  dispatching  and  call  management  capabili- 
ties with  problem  escalation  and  parts  usage/tracking  functionality. 

Almost  all  systems  provide  some  level  of  accounting  capability,  such  as 
billing,  efficiency  reporting,  and  P&L  analysis. 
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EXHIBIT  V-1 

FUTURE   FSMS  FUNCTIONALITY 

•  Accounting  (Including  invoicing) 

•  Call  Handling/Dispatching 

•  Efficiency  Reports 

•  Information  (e.g.,  Customer  Histories) 

•  Parts  Tracking 

•  Training  Utilizing  CD-ROM  and  CAI 

•  Remote  Diagnostics 

•  Remote  Service  Implementation 


I 

FT01-15b  -54- 


©1987  by  INPUT.  Reproduction  Prohibited. 


INP 


Most  provide  some  level  of  integration,  allowing  the  use  of  one  central 
data  base  that  can  provide  a  wide  range  of  informational  reporting 
capabilities,  such  as  customer  and  product  histories. 

Unfortunately,  few  systems,  whether  packaged  or  in-house  developed,  excel  at 
integrating  remote  support  activities.  Less  than  half  of  the  packaged 
software  systems  surveyed  provided  diagnostic  capabilities  (and  most  of  these 
were  relatively  crude  diagnostics,  at  that)  and  less  than  30%  of  the  in-house 
systems  sampled  provide  any  remote  support  integration  (typically,  these 
capabilities  were  managed  through  a  separate  system).  Again,  if  the  goal  of 
automating  service  delivery  is  to  cut  down  on  expensive,  labor-intensive 
activities,  then  the  implementation  and  integration  of  remote  support  services 
with  the  service  management  process  is  a  necessity. 

A  likely  service  call  scenario  would  then  be  as  follows; 

A  system  interruption  occurs,  and,  depending  on  the  level  of  remote 
support  used,  either  the  system  begins  servicing  itself,  or  the  system 
alerts  either  the  user  or  a  remote  support  center  technician. 

If  the  system  itself  cannot  overcome  or  circumvent  the  problem,  an  on- 
site  FE  is  dispatched  automatically  with  information  about  the  user, 
equipment,  problem,  parts  necessary,  and  relevant  service  information. 

Upon  service  completion,  whether  remotely  performed  or  completed 
on-site  by  the  FE,  the  call  is  closed  out,  automatically  updating  the 
FSMS  central  data  base. 

A  clear-cut  benefit  of  this  capability  is  that  all  service  information  and 
activities  are  tracked  and  stored  in  one  location,  increasing  the  number  and 
scope  of  reports  possible.  For  example,  this  type  of  system  would  not  only  be 
able  to  track  system  interruptions  but  also  the  number  of  interruptions 
handled  by  remote  support  versus  on-site  and  the  MTTRepairs  resulting  from 
both  support  methodologies. 
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An  area  of  tremendous  potential  benefit  to  service  and  support  is  artficia! 
intelligence  (AI)  and  expert  systems  (ES).  Basically,  AI  is  a  duplication  of 
processes  by  which  humans  perceive  and  assimiliate  data  and  use  reasoning  to 
process  this  data.  For  most  purposes,  this  duplication  is  performed  so  that 
computers  can  make  decisions  based  on  reasoning.  Expert  systems  are 
advanced  applications  of  AI  processes,  usually  involving  software  that  permits 
inferences  based  on  inquiries  made  to  a  central  data  base.  In  such  applica- 
tions, emphasis  is  placed  on  the  machine's  ability  to  recognize  and  identify 
patterns  and  make  decisions  based  on  those  pattern  recognitions.  Exhibits  V-2 
and  V-3  summarize  the  benefits  of  AI  and  expert  systems. 

In  service,  AI  and  expert  systems  can  be  effectively  used  to  supplement  on- 
site  and  remote  diagnostics.  Such  systems  are  already  being  used  in  similar, 
diagnosis-intensive  industries  (e.g.,  medicine,  engineering,  and  science)  and 
can  easily  incorporate  currently  available  service  histories  contained  in  most 
FSMS  systems. 

Although  opponents  of  increased  automation  point  to  concerns  from  FEs  who 
fear  that  such  systems  will  replace  human  thought,  the  use  of  AI  and  expert 
systems  will  free  human  thought  of  more  routine  activities  and  concentrate  on 
intrepreting  the  system's  analyses.  Specifically,  use  of  such  systems  will  free 
FEs  from  constant  retraining  on  new  equipment  and  allow  the  FE  to 
concentrate  more  on  customer  interface  skills. 

Many  service  organizations  have  already  incorporated  (or  at  least  studied)  the 
application  of  AI  into  their  service  strategy.  IBM  has  reported  productivity 
improvements  of  20-30%  in  limited  applications  of  expert  systems  in  servicing 
peripheral  products.  Texas  Instruments  has  been  actively  experimenting  with 
AI  applications  for  at  least  four  years  and  hopes  to  be  able  to  incorporate  AI 
into  its  own  FSMS  system.  Field  Information  System-II  (FlS-li).  General 
Electric  offers  an  expert  system  for  railroad  locomotive  maintenance  and  will 
soon  release  a  similar  system  for  jet  engine  maintenance.  Tektronix  offers  a 
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ARTIFICIAL  INTELLIGENCE 

•  Expert  Systems 

•  Intelligent  Computer-Aided  Instruction 

•  Pattern  Recognition 

•  Voice  Recognition 

•  Robotics 
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EXHIBIT  V-3 


{ 


EXPERT  SYSTEMS 

•  Advanced  Ai  Application 

•  Permit  Inferences  Based  Upon  DB  Inquiries 

•  Employ  Symbolic  Representations 

•  Use  Heuristics  Search  Methodology 

•  May  Provide  "Fall-Back"  Problem  Resolution 

•  Present  Recommendations  and  Explain  Why 
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less  developed  system  for  peripheral  diagnostics  that  acts  as  a  service 
tutorial,  recommending  specific  service  activities. 

HANDHELD  TERMINALS 

While  handheld  terminals  have  been  used  specifically  by  service  organizations 
for  only  a  short  time,  the  development  of  such  tools  has  been  aided  by 
technological  advances  in  microprocessor  design  that  resulted  in  more 
computing  and  communications  capabilities.  The  current  products  seem  to  be 
the  best  compromise  between  portability  and  functionality;  however,  future 
products  will  undoubtedly  improve  upon  the  size/functionality  mix. 

Key  improvements  will  be  in  the  data  entry  aspects  of  the  terminals.  An 
obvious  requirement  of  these  terminals  is  to  avoid  having  the  FE  spend 
significant  amounts  of  time  entering  data  into  the  terminal,  which  in  effect 
equates  to  a  highly  skilled,  highly  paid  engineer  (functionally)  replacing  a  data 
entry  clerk.  Previous  terminal  designs  have  avoided  this  by  requiring  coded 
responses  and  scrolling  capabilities  to  lessen  the  amount  of  keyboard  entry. 
Some  systems  have  supplemented  these  with  bar  code,  or  wand  reader 
expansion  capabilities,  yet  the  current  technology  which  requires  the  reader 
to  touch  the  coded  part,  assembly,  or  subassembly  cannot  be  used  for  most 
service  applications  for  fear  of  magnetic  or  other  contamination  concerns. 

Instead,  advances  in  laser  technology  will  allow  FEs  to  use  a  wand  reader  to 
pick  up  part,  board,  subassembly,  and  assembly  numbers  with  little  fear  of 
magnetic  or  dust  contamination. 

Furthermore,  future  handheld  terminals  will  improve  their  integration  with 
the  computer  system's  diagnostics  function,  improving  problem  determination 
activities.  This  ability  will  be  further  improved  if  the  terminals  incorporate 
artificial  intelligence  or  expert  systems  capabilities. 
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REMOTE  DIAGNOSTICS/SUPPORT 


i 


Remote  diagnostics  have  provided  the  greatest  amount  of  service  advance- 
ment in  the  past  few  years.  Most  current  systems  have  incorporated  some 
level  of  diagnostic  capability,  and  the  more  advanced  systems  have  expanded 
the  level  of  remote  activities  available  to  that  of  actual  support  implementa- 
tion. This  capability  is  more  common  on  the  software  side,  with  downline 
loading  of  software  "fixes"  the  most  economically  accceptable  of  providing 
prompt  problem  resolution  to  the  users. 

On  the  hardware  side,  such  remote  support  implementation  is  more  commonly 
associated  with  multiprocessor  and  "fault-tolerant"  systems,  where  a  failed 
board,  component,  or  even  processor  can  be  circumvented  until  replacement 
of  the  failed  unit  can  be  scheduled.  In  this  fashion,  support  becomes  less 
reactive  as  the  scheduled  replacement  occurs  prior  to  catastrophic  system 
failure  and  at  a  time  that  least  impacts  the  operations  of  the  system. 

Future  remote  support  technology  will  certainly  benefit  from  AI  and  expert 
systems  applications  as  more  companies  follow  the  lead  of  IBM  and  Digital 
Equipment  Corporation  in  developing  automated  tools  to  aid  in  the  diagnosis 
and  repair  of  computer  systems. 


i 
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Appendix  A:  Questionnaire 


Was  your  current  service  management  system  developed  in-house  or  purchased  from  another  source? 

a.  in-house 

b.  purchased  from  SW  vendor  specify  

c.  purchased  from  another  source   specify   

Does  your  system  provide  the  following  features: 

a.  dispatching  /  call  management   

b.  messaging   

c.  parts  tracking  /  inventory  .   

d.  customer  /  site  history   

e.  product  information  ' 

f.  billing  /  invoicing   

g.  other  accounting  functions   

h.  manpower  efficiency  reports   

i.  P  &  L  analysis   

j.  diagnostics   

k.  training  (service  instructions)   

1.  support  implementation   

If  the  system  provides  diagnostic  capabilities,  are  they: 

a.  user-run   

b.  FE-run   

c.  remotely-run   

d.  system-run   

Please  describe  the  level  of  diagnostics  performed  
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Is  your  system  centralized,  regionally  located  and  operated,  or  decentralized  (at  office  level)? 

a.  centralized   

b.  regional   

c.  decentralized   

Please  rate  your  requirements  for  the  following  functions  of  an  automated  service  management  system 
(on  a  scale  of  1-10, 10=highest): 

Requirement 

a.  dispatching   

b.  parts  tracking   

c.  accounting  (inc.  billing)   

d.  informational  (e.g.,  site  /  product  histories)   

e.  training  /  service  instruction   

f.  manpower  /  office  studies   

g.  diagnostics   

h.  service  implementation   

How  would  you  describe  the  "ideal-type"  (future)  service  management  system? 


i 
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APPENDIX  B:  DEFINITIONS 


•  APPLICATIONS  SOFTWARE  -  Software  that  performs  processing  to  service 
user  functions. 

•  ARTIFICIAL  INTELLIGENCE  -  The  academic  discipline  involving  the  study  of 
the  processes  by  which  humans  perceive  and  assimilate  data  (and  use 
reasoning  to  process  this  data)  for  the  purpose  of  duplicating  these  processes 
within  computer  systems.  Also,  this  term  refers  to  the  computer  systems  that 
accomplish  these  duplicated  processes. 

9         BOC  -  Bell  Operating  Company. 

•  CONSULTING  -  Includes  analysis  of  user  requirements  and  the  development  of 
a  specific  action  plan  to  meet  user  service  and  support  needs. 

•  DISPATCHING  -  The  process  of  allocating  service  resources  to  solve  a 
support-related  problem. 

•  DIVESTITURE  -  The  action,  stemming  from  antitrust  lawsuits  by  the  Depart- 
ment of  Justice,  which  led  to  the  break-up  of  AT&T  and  its  previously  owned 
local  operating  companies. 

•  DOCUMENTATION  -  All  manuals,  newsletters,  and  text  designed  to  serve  as 
reference  material  for  the  ongoing  operation  or  repair  of  hardware  or 
software. 
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END  USER  -  May  buy  a  system  from  the  hardware  supplier(s)  and  do  own 
programming,  interfacing,  and  installation.  Alternatively,  may  buy  a  turnkey 
system  from  a  systems  house  or  hardware  integrator. 

EXPERT  SYSTEMS  APPLICATIONS  -  Applications  for  expert  systems-a 
computer  system  based  on  a  data  base  created  by  human  authorities  on  a 
particular  subject.  The  computer  system  supporting  this  data  base  contains 
software  that  permits  inferences  based  on  inquiries  against  the  information 
contained  in  the  data  base.  Expert  systems  is  often  used  synonymously  with 
"knowledge-based  systems,"  although  this  latter  term  is  considered  to  be 
broader  and  to  Include  expert  systems  within  its  scope. 

ENGINEERING  CHANGE  NOTICE  (ECN)  -  Product  changes  to  improve  the 
product  after  it  has  been  released  to  production. 

ENGINEERING  CHANGE  ORDER  (ECO)  -  The  followup  to  ECNs  which 
include  parts  and  a  bill  of  material  to  effect  the  change  in  hardware. 

ESCALATION  -  The  process  of  increasing  the  level  of  support  when  and  if  the 
field  engineer  cannot  correct  a  hardware  or  software  problem  within  a 
prescribed  amount  of  time,  usually  two  to  four  hours  for  hardware. 

FIBER  OPTICS  -  A  transmission  medium  which  uses  lightwaves. 

FIELD  ENGINEER  (FE)  -  For  the  purpose  of  this  study,  field  engineer, 
customer  engineer,  serviceperson,  and  maintenance  person  were  used  inter- 
changeably and  refer  to  the  individual  who  responds  to  a  user's  service  call  to 
repair  a  device  or  system. 

FIELD  SERVICE  MANAGEMENT  SYSTEM  (FSMS)  -  A  specialized  application 
program  that  automates  some  (If  not  all)  of  the  following  activities  of  a  field 
service  organization:   call  handling,  dispatching,  parts  Inventory  and  tracking, 
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billing,  efficiency  reporting,  and  other  functions.  Ideally,  the  system  accesses 
one  data  base  from  which  each  function  can  use  and  modify  data. 

HARDWARE  INTEGRATOR  -  Develops  system  interface  electronics  and 
controllers  for  the  CPU,  sensors,  peripherals,  and  all  other  ancillary  hardware 
components.  May  also  develop  control  system  software  in  addition  to 
installing  the  entire  system  at  the  end-user  site. 

ISDN  -  Integrated  Services  Digital  Network.  A  proposed  standard  for  digital 
networks  providing  transport  of  voice,  data,  and  image  using  a  standard 
interface  and  twisted  pair  wiring. 

LADT  -  Local  Area  Data  Transport.  Data  communications  provided  by  the 
BOCs  within  local  access  transport  areas  (LATA). 

LARGE  SYSTEM  -  Refers  to  traditional  mainframes  including  at  the  low  end 
IBM  4300-like  machines  and  at  the  high  end  IBM  308X-like  machines.  Large 
systems  have  a  maximum  word  length  of  32  bits  and  a  standard  configuration 
price  of  $350,000  and  higher. 

MEAN  TIME  BETWEEN  FAILURES  (MTBF)  -  The  elapsed  time  between 
hardware  failures  on  a  device  or  a  system. 

MEAN  TIME  TO  REPAIR  -  The  elapsed  time  from  the  arrival  of  the  field 
engineer  on  the  user's  site  until  the  device  is  repaired  and  returned  to  the  user 
for  his  utilization. 

MEAN  TIME  TO  RESPOND  -  The  elapsed  time  between  the  user  placement  of 
a  service  call  and  the  arrival  at  the  user's  location  of  a  field  engineeer. 

MICROCOMPUTER  -  A  microprocessor-based  single-  or  multi-user  computer 
system  typically  priced  less  than  $15,000.  A  typical  configuration  includes  an 
8-  or  16-bit  CPU,  monitor,  keyboard,  two  floppy  disk  drives,  and  all  required 
cards  and  cables. 
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MINICOMPUTER  -  See  Small  System. 

OPERATING  SYSTEM  SOFTWARE  (SYSTEMS  SOFTWARE)  -  Software  that 
enables  the  computer  system  to  perform  basic  functions.  Systems  software, 
for  the  purposes  of  this  report,  does  not  include  utilities  or  program 
development  tools. 

PBX  -  Private  Branch  Exchange.  A  customer  premises  telephone  switch. 

PERIPHERALS  -  Includes  all  input,  output,  and  storage  devices,  other  than 
main  memory,  which  are  locally  connected  to  the  main  processor  and  are  not 
generally  included  in  other  categories,  such  as  terminals. 

PLANNING  -  Includes  the  development  of  procedures,  distribution,  organiza- 
tion, and  configuration  of  support  services.  For  example,  capacity  planning, 
"installation"  planning. 

PLUG-COMPATIBLE  MAINFRAME  (PCM)  -  Mainframe  computers  that  are 
compatible  with  and  can  execute  programs  on  an  equivalent  IBM  mainframe. 
The  two  major  PCM  vendors  at  this  time  are  Amdahl  and  National  Advanced 
Systems. 

PROFESSIONAL  SERVICES  -  A  category  services  including  system  design, 
custom  programming,  consulting,  education,  and  facilities  management. 

RBOC  -  Regional  Bell  Operating  Company.  One  of  seven  holding  companies 
coordinating  the  activities  of  the  BOCs. 

REMOTE  DIAGNOSTICS  -  Gaining  access  to  a  computer  from  a  point 
physically  distant  from  the  computer  in  order  to  perform  problem 
determination  activities. 
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REMOTE  SUPPORT  IMPLEMENTATION  -  An  extension  of  remote  diagnostics 
where  some  level  of  support  delivery  is  performed  from  a  point  physically 
distant  from  the  computer.  Currently,  this  capability  is  more  common  to 
software  support  where  problems  can  be  solved  or  circumvented  through 
downline  loading  of  new  code  (fixes). 

RESELLER  -  A  marketing  organization  which  buys  long-distance  capacity  for 
others  at  wholesale  rates,  selling  services  at  retail  but  discounted  prices  and 
profiting  on  the  difference. 

SMALL  BUSINESS  COMPUTER  -  For  the  purpose  of  this  study,  a  system 
which  is  built  around  a  Central  Processing  Unity  (CPU),  has  the  ability  to 
utilize  at  least  20M  bytes  of  disk  capacity,  provides  multiple  CRT  work- 
stations, and  offers  business-oriented  system  software  support. 

SMALL  SYSTEM  -  Refers  to  traditional  minicomputer  and  superminicomputer 
systems  ranging  from  a  small  multi-user,  16-bit  system  at  the  low  end  to 
sophisticated  32-bit  machine  at  the  high  end. 

SOFTWARE  DEFINED  NETWORK  -  A  private  network  which  uses  public 
network  facilities  and  which  is  configurable  on  an  as-needed  basis  by  the  user 
(see  Virtual  Private  Network). 

SOFTWARE  ENGINEER  (SE)  -  The  individual  that  responds  (either  on-site  or 
via  remote  support)  to  a  user's  service  call  to  repair  or  patch  operating 
systems  and/or  applications  software. 

SOFTWARE  PRODUCTS  -  Systems  and  applications  packages  which  are  sold 
to  computer  users  by  equipment  manufacturers,  independent  vendors,  and 
others.  Also  included  are  fees  for  work  performed  by  the  vendor  to 
implement  a  package  at  the  user's  site. 

SUPERMINICOMPUTER  -  See  Small  System. 
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•  SYSTEMS  INTEGRATION  -  The  action  of  a  single  service  vendor's  design, 
development,  and  implennentation  of  a  systenn  or  subsystem  including  integra- 
tion of  hardware,  software,  and  communications  facilities  for  a  customer. 

•  SYSTEM  INTERRUPTION  -  Any  system  downtime  requiring  an  Initial  Program 
Lod  (IPL). 

•  SYSTEMS  HOUSE  -  Integrates  hardware  and  software  into  a  total  turnkey 
system  to  satisfy  the  data  processing  requirements  of  the  end  user.  May  also 
develop  system  software  products  for  license  to  end  users. 

•  T- 1  -  Refers  to  a  standard  1.544  megabit  per  second  digital  channel  used 
between  telephone  company  central  offices  and  is  now  used  for  microwave, 
satellite,  fiber  optics,  or  other  bypass  applications. 

•  THIRD-PARTY  MAINTENANCE  (TPM)  -  Any  service  provider  other  than  the 
original  equipment  vendor. 

•  TRAINING  -  All  audio,  visual,  and  computer-based  documentation,  materials, 
and  live  instruction  designed  to  educate  users  and  support  personnel  in  the 
ongoing  operation  or  repair  of  hardware  and  software. 

•  TURNKEY  SYSTEM  -  Composed  of  hardware  and  software  integrated  into  a 
total  system  designed  to  completely  fulfill  the  processing  requirements  of  a 
single  application. 

•  VSAT  -  Very  Small  Aperture  Terminal.  A  small  satellite  dish  system,  usually 
using  Ku-band  frequencies. 

•  VIRTUAL  PRIVATE  NETWORK  -  A  portion  of  a  public  network  dedicated  to  a 
single  user. 
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APPENDIX  C:         RESPONDENT  COMPANIES 


Amdahl  Corporation. 

Data  General  Corporation, 

Dataserv  Inc. 

First  Data  Resources, 

Gould. 

ITT/Servcom. 
Inteiogic  Trace. 

McDonnell  Douglas  Field  Service  Company. 
Memorex  Corporation. 
National  Advanced  Systems. 
Stratus  Computer,  Inc. 
Sun  Microsystems,  Inc. 
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TRW  Customer  Service  Division. 
Tandem  Computer. 
Total  Technical  Services. 
Unisys  Corporation. 
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INPUT  provides  planning  information,  analysis,  and 
recommendations  to  managers  and  executives  in  the 
information  processing  industries.  Through  market 
research,  technology  forecasting,  and  competitive 
analysis,  INPUT  supports  client  management  in 
making  informed  decisions.  Continuing  services  are 
provided  to  users  and  vendors  of  computers, 
communications,  and  office  products  and  services. 

The  company  carries  out  continuous  and  in-depth 
research.  Working  closely  with  clients  on  important 
issues,  INPUT'S  staff  members  analyze  and  inter- 
pret the  research  data,  then  develop  recommen- 
dations and  innovative  ideas  to  meet  clients'  needs. 


About  INPUT 


Clients  receive  reports,  presentations,  access  to  data 
on  which  analyses  are  based,  and  continuous 
consulting. 

Many  of  INPUT'S  professional  staff  members  have 
nearly  20  years'  experience  in  their  areas  of  speciali- 
zation. Most  have  held  senior  management  positions 
in  operations,  marketing,  or  planning.  This  exper- 
tise enables  INPUT  to  supply  practical  solutions 
to  complex  business  problems. 

Formed  in  1974,  INPUT  has  become  a  leading 
international  planning  services  firm.  Clients  include 
over  100  of  the  world's  largest  and  most  techni- 
cally advanced  companies. 
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